The invention is related to the field of representation and translation of electronic documents.
Some documents have fields that must be combined or massaged to produce data that matches a desired xe2x80x9cmeaningxe2x80x9d. For example, in a document, the following structure may be present in Document1:
Store_Identifier (group)
DUNS_Number (9-digit field)
Store_Number (4-digit field)
And in Document2:
Location (11-digit field)
Where the Location is the DUNS_Number with the Store_Number concatenated to it. In this case, a xe2x80x9cmeaningxe2x80x9d is part of multiple fields in Document1.
Conventional solutions to mapping require users to write customized code to handle such cases. For example, suppose Vendor1 has a mapping tool that Customer1 uses. Customer1 is mapping Document1 to Document2. Customer1 writes code like:
Target.Location=concat(Source.Store_Identifier.DUNS_Number, Source.Store_Identifier.Store_Number)
Locations in a document can have more than one meaning. This means that mapping is hard to automate. Instead, the mappings must be manually done and require customized code, which does not allow reuse of mapping knowledge and rules.
Conventional solutions have several disadvantages. First, both mapping and the mapping rules are one-off. That is, each time a user wants to define how to perform a document translation, similar code must be written and tested. This increases the time needed to define how to translate from the source to the target document.
Furthermore, both mapping and the mapping rules depend on user-written code. This makes it hard to automatically validate the integrity of the mapping. It also sets a minimum bar for the skill level of anyone trying to define a mapping, as they must then know all the document locations that might hold a particular meaning, and must be skillful enough to write the code to handle the case. This imposes a maintenance burden, as fixing a problem in a mapping requires altering code.
The mapping and the mapping rules are translation-language dependent. The code that must be written and tested depends on the underlying translation engine that will translate the documents. Thus, mapping rules will be translation-engine dependent, and that a translation defined for one translation engine will likely need adjusting to make the mapping work on a different translation engine. Moving a transform from one translation engine to another is difficult.
The source and target mappings must be significantly different. The code for handling the case described above will differ whether the document is the source or the target document. If one has mapped from A to B, mapping from B to A requires major rework, as the code for the mapping would have to be re-written using different logic.
Conventional mapping tools previously use superficial similarities in field names or document structure as the basis for automapping. They can not automap to virtual structures, forcing users to write code.
A method comprising defining one or more aggregate virtual fields for a first document using meta-data associated with the first document is disclosed.